Magnetic tape provides a means for physically storing data which may be archived or which may be stored in storage shelves of automated data storage libraries and accessed when required. Data stored in this manner has an aspect of permanence which allows copies of the data stored in memory or disk at a host system to be erased, knowing that a copy exists on involatile magnetic tape. The available storage space at the host system is relatively expensive, and there is a desire to release the storage space as soon as possible, so that it may be overwritten. Additionally, some host applications are designed with a simple algorithm, in which they do not proceed to processing data beyond the data that has been sent, until they see a Command Complete returned for the just issued store command. This simplifies the host application processing.
Thus, it is often desirable to “synchronize” the data.
“Synchronized data” is defined as data or other information which is subject to a “synchronizing event” or similar command requiring the tape drive to not return “Command Complete” to a write type of command, or an indication that the command has been or will be successfully executed, until it has actually committed the data to involatile media, specifically, in the case of a tape drive, to magnetic tape. As the result, if power is lost or the tape drive fails, the data can be recovered from the tape, whereas it may not be recoverable from a volatile DRAM storage of the tape drive buffer.
One example of a synchronizing event is a Write Filemark command with the Immediate bit set to “0”. This means that the drive is not to respond immediately, but instead is to respond when the command has completed, meaning that any data sent as part of the command is written out to tape. A specialized case of a Write Filemark command is where the number of Filemarks field is also set to “0”, meaning that the Write Filemark command has no data of its own, and all data which precedes the command must be written to tape before a command complete is sent. Hence, this command is often referred to as a “Synchronize” command, as is known to those of skill in the art.
Another example of a synchronizing event is a host selectable write mode known to those of skill in the art as “non-buffered writes”, where an implicit synchronize must be performed after each record is written from the host. “Command Complete” is not returned for any write command until the data is successfully written on tape media.
Herein, writing any data record, group of records, or other mark, is defined as a “transaction”, and writing such data record, etc., as the result of a synchronizing event is defined as a “synchronized transaction”.
A difficulty with respect to magnetic tape is that the data is recorded sequentially without long gaps between data sets, such that the data is typically recorded in a continuous fashion as much as is possible.
Typically, the data to be written to magnetic tape is staged to a buffer at the tape drive, and the synchronizing event requires that, in writing the synchronized data to magnetic tape, all data in the buffer preceding the synchronized data also be written to tape preceding the data to be synchronized. Additionally, since no data is typically sent to the drive after the drive is sent the synchronizing command and before the Command complete is sent back (to do so would require command queueing of data commands, something which is almost never supported by a tape drive), this has the effect of emptying the buffer. Thus, the synchronized transactions are stored in separate bursts for each synchronizing event, with a noticeable time period before writing the next transaction. This requires that the tape drive “backhitch” after writing the synchronized transaction, in order to write the next transaction closely following the preceding transaction. In the example of a simplified host application as discussed above, the application does not proceed to processing data beyond data that has already been sent until it sees a Command Complete returned for the just issued synchronizing command. This simplifies the host application processing, but at the cost of performance, since it guarantees that the tape drive will run out of data in the buffer before it can issue a Command Complete, thus forcing the tape drive to backhitch. Tape is written or read while it is moved longitudinally at read/write speed. Hence, a backhitch requires that the tape be stopped, reversed to beyond the end of the previous transaction, stopped again, and accelerated up to speed in the original direction by the time that the end of the previous transaction is reached. As is understood by those of skill in the art, the backhitch process consumes a considerable amount of time, and, if a large number of small synchronized transactions are to be stored, the throughput of the tape drive can be reduced dramatically. As an example, backhitch times can vary from about half a second to over three seconds.
Disk drives are typically random access, and may store data without requiring backhitches, but are expensive as compared to magnetic tape, such as magnetic tape cartridges. Hence, disk drives are typically employed, not for the permanent storage of data, but, rather, for the storage of data which is being used by the system, or for the operating system and applications of the system.
Staging buffer systems, such as large capacity disk drive buffer systems, have been employed to provide a physical storage for the data while waiting for the data to be permanently stored to magnetic tape, but, especially in smaller system environments, staging buffer systems are considered expensive, and are avoided if possible. In the larger systems, the staging buffer systems are also considered expensive, and are typically limited in capacity, such that they need to be overwritten as soon as possible. Thus, data to be synchronized is provided to magnetic tape drives in such systems.